LAYER 1: EXECUTIVE CONTEXT (Cody's Notes)

LAYER 2: CORE PHILOSOPHY (The Narrative Summary)

Overview

This article addresses one of the most persistent and highly debated frictions in modern software engineering: the relationship between software estimation practices and Agile methodologies. Often viewed as opposing forces—friends or foes—the tension stems from the business's demand for predictability versus software development's inherent uncertainty and uniqueness. The article explores how this relationship can be salvaged, positioning estimations not as rigid deadlines, but as tools for decision-making and planning, while warning against common anti-patterns that derail developer productivity.

Why Software Estimations Differ

Traditional industries (e.g., construction, manufacturing) can rely on historical data to predict timelines because the work is highly repeatable. Software development, however, is fundamentally unique; no two systems are identical. As a result:

• The Cone of Uncertainty: At the beginning of a project, the level of uncertainty is at its peak. It is only through exploration, design, and code delivery that this uncertainty narrows. Upfront estimations are naturally prone to extreme variance, making them rough forecasts rather than commitments.
• Uniqueness of Software: Software engineering is an exercise in continuous discovery. Estimating a unique design is akin to estimating the time required to solve a problem that has never been solved in this exact context before.

Common Pitfalls and the "Foe" Dynamic

Estimations become a "foe" to Agile when:

1. Estimates Become Deadlines: Business stakeholders frequently mistake an estimation for a hard commitment. This "commitment trap" leads to rushed work, technical debt, and team burnout when unforeseen complexities arise.
2. Velocity as a Weapon: Using metrics like velocity or completed story points to evaluate developer performance instead of for team planning. This encourages teams to "game the system" by inflating estimates, destroying trust, and reducing systemic velocity.
3. Wasted Overhead: Spending excessive time in ceremonies attempting to refine estimates to a degree of precision that is mathematically impossible early in the Cone of Uncertainty.

Relative Estimation and the Search for Predictability

To reconcile these challenges, teams use relative estimation models:

• Story Points & Fibonacci Sequence: By sizing tasks relative to a known baseline using the Fibonacci sequence (1, 2, 3, 5, 8, 13...), teams acknowledge that uncertainty grows with task size. The gaps in the sequence prevent "fake precision."
• Planning Poker: Designed to facilitate debate. The value of Planning Poker lies not in the final point value, but in the collaborative discussion that surfaces assumptions, dependencies, and hidden risks.
• The /#NoEstimates Perspective: An alternative approach where teams break work into small, uniform items and use empirical flow metrics (like throughput and cycle time) to forecast progress, eliminating estimation overhead.

Connection to Category 1: Developer Productivity and Throughput

This article directly supports Category 1 by framing estimation as a tool for workflow optimization rather than control. By understanding that estimation is an exercise in risk mitigation and alignment, engineering leaders can lower cognitive load, protect their teams from artificial deadlines, and design high-throughput systems that prioritize empirical flow and continuous discovery.

Generated for the Product Growth Program.

LAYER 3: FULL REFERENCE (Raw Article Content)

URL Source: https://itnext.io/software-estimations-and-agile-friends-or-foes-e1e5250aefb5

Software estimations and agile have been under heavy criticism for a while, so nothing better than putting them together in the same article and seeing what happens. After witnessing numerous discussions due to requests to plan or provide estimates, it became clear that there was an interesting point worth investigating further. Let’s begin by examining the common problems reported and then suggest why you may be approaching each one — or both — incorrectly, and more importantly, a better alternative.

Software Estimations Are Useless

Estimates are part of most activities that I know of. How long to prepare food, for the movie to begin, for the doctor to operate, to assemble a car, etc. Yet, when we try to transpose the practice of estimation on software development, we stumble across the first difference in this practice versus the others: uniqueness.

The underlying story is that we only seem to know how long it will take once we finish! After all, no two applications are truly equal and as discoveries and solutions emerge, your original idea tends to seem far from reality. The cone of uncertainty can be used to explain the reason.


Figure 1. The uncertainty decreases as the progress happens

One conclusion is that providing software estimates is a futile exercise. Since whatever we think we know is likely to change, anything I come up with as an estimate will be wrong and of little value.

Scrum Means No Plans

Agile methodology appeared as a way to address recurring problems with software development, including "inflexible" responses to changing requirements, poor stakeholder communication, excessive overhead, unreliable delivery timelines, and the frequent mismatch between delivered software and evolving user needs.

Those who follow Scrum embrace the fact that as we know more about the problem space, we refine the requirements, and so our product backlog. However, this is often translated as focusing solely on the current sprint backlog with little consideration to what lies ahead, much less to what we understand to be the end goals.

One conclusion is that there is no need (or value) in having a plan that showcases the end. We are supposed to deliver a working iteration at every sprint, so it will be done when it is done.

A Marriage Made in Hell?

Not so fast. The problems with the previous conclusions, more common than you can think of, are the following:

• Estimates have to be perfect

Estimates are not single values, but distributions. That means that they come with a variance that provides a range where it is still considered valid. For example, one practice when estimating is to associate that estimate with an X% certainty of being within a Y% variance (+-).


Figure 2. A fictitious distribution of an estimate of 2 weeks, 25% variance and 75% certainty.

• I don’t know how to effectively estimate

In the book Software Estimation: Demystifying the Black Art, there are more than 10 different methods to perform software estimation. However, the number of developers who have been exposed to any of the ones presented during their career is small. Don't trust me? Ask around…

It is no surprise that when asked to estimate the development of a feature, a fair number of developers are unable to explain, or justify, how they reached their numbers without a lingering “it should fit the worst case” approach.

• I miss the point of what estimates are good for

Estimates, while presented as a number (2 weeks, story points, sprint devs), serve as discussion points. At the very least, they show how (un)clear the requirements and goals are.

They are meant to kick off a healthy discussion on the understanding and trade-offs that can be established while pursuing the same goals.

• Plans have to be perfect

Plans are meant to be revisited and changed for the right reasons! This means that one should avoid going down the rabbit hole and end up in analysis paralysis, looking for a perfect representation of your goals.

Instead, we should be focusing on understanding the bigger picture, identifying the main sources of risk.

As you refine the requirements, your plan should be adjusted accordingly.

A potential measure of the quality of your plan is associated with the number of activities you discard. If you over-detailed the plan ahead of time, chances are you will have to throw most of it away.

• I miss the point of what planning is good for

Like estimations, plans provide discussion points on what has been understood as the problem (what) and the proposed solution (how).

If you can plan at the right level, you will be the first to highlight when something is unclear, decide whether it is part of a critical path, or if it can be deferred.

• Ignore practical reality

The “it is done when it is done” is simply not true in real life, at least in most companies. Finite budgets and customer expectations are just two of the things that we should never forget.

Even R&D, proof-of-concept (PoC) approaches must have some guardrails to signal when it is time to stop.

Solutions

Now that we have discussed some of the problems and misconceptions, how can we improve?

The good news is that most of the previous problems can be solved by adjusting your understanding of the reason and importance that the plan and estimations have. The bad news is that this requires acknowledging the need to change habits.

There is no new algorithm, language, or specific tool to master, but taking the time to take these assignments and discuss with your peers and your product team, so you are both aligned on the reasons to do them.

Estimates Made Easy

While many techniques can be used, some more complex than others, the choice may depend on your particular case/industry.

However, one method that I find easy to apply and marries the agile mentality is the work breakdown structure (WBS).

Under WBS, you take your project/feature and break it down as a list of smaller units (tasks). Then you estimate each task, and at the end, sum up all the values.

WBS works because breaking down a feature forces you to think through the steps. Estimating the whole in one shot makes reasoning and justification harder.


Figure 3. Same feature can be more easily/precisely estimated if broken down into smaller units.

With a WBS, you are assessing a smaller piece, where not only can you reason about it, but more easily explain or adjust based on opinions from others.

The advice here is to avoid the trap of thinking that this becomes a synonym of the story planning or a too-detailed list containing lower-level elements that are not significant to the critical path or effort. Otherwise, this exercise will go on for longer than the precision it can provide warrants.

By the way, you can do a WBS Scrum-style, where you can make the breakdown first and have planning poker.

We Can All Be Friends

Estimation practices and Agile were created to help us achieve certain goals, but neither extreme is a desirable place to be.

Software estimates can be valuable if approached with the right attitude and purpose. The same applies to having a plan and using it as part of your Agile team.

Start simple, practice the WBS, and estimate the tasks. Talk to your product team about the estimates and learn from what went well and what could improve.

Rinse and repeat!

Discussion Questions

1. The article argues that the uniqueness of software development is why estimation is often seen as futile. Can you think of non-software activities where estimates are also highly uncertain due to a high degree of uniqueness, and how those industries approach the "cone of uncertainty"?
2. The article challenges the notion that "Scrum Means No Plans," stating that this leads to "focusing solely on the current sprint backlog with little consideration to what lies ahead." In your experience, how can a Scrum team effectively plan for the end goal and mitigate major risks without falling into "analysis paralysis"?
3. The article emphasizes that estimates are not single values but distributions that come with a variance and certainty (e.g., X% certainty of being within Y% variance). Why is communicating an estimate as a range or probability—rather than a single number—crucial for managing stakeholder expectations?
4. The article states that estimates and plans are primarily meant to serve as "discussion points." Can you share an experience where an estimate (accurate or inaccurate) led to a valuable discussion or a necessary trade-off that improved the project outcome?
5. The Work Breakdown Structure (WBS) is offered as an effective, simple estimation technique because it "forces you to think through the steps." How can a team ensure that breaking down a feature into tasks using WBS doesn't lead to over-detailing tasks that are not on the critical path or won't significantly impact the overall effort?
6. The article notes that many developers have little exposure to formal estimation methods. What practical steps can teams or organizations take to train developers and product managers in effective estimation techniques like WBS or others, and build confidence in their results?
7. The "Ignore practical reality" section highlights that "Finite budgets and customer expectations" mean the "it is done when it is done" mindset is often untrue. How can Agile teams reconcile the need for flexibility and evolving requirements with the fixed constraints of a budget or a hard customer deadline?
8. The author concludes that the solution isn't a new tool, but an adjustment of understanding and a change in habits. What is the most common misconception or bad habit you've seen regarding planning or estimating, and what is the single most important habit change that can make a team's estimates more valuable?
9. The article is essentially arguing for a middle ground where estimation and planning are embraced with an Agile mindset. If you were coaching a development team, what one piece of advice would you give them to ensure they use their estimates and plans as tools for discussion and risk management rather than as inflexible, perfect commitments?

Generated for the Product Growth Program.